The emergence of new digital audiovisual equipment such as video cassette recorders, camcorders, multimedia computers, and so on, means that it is now essential to use a high speed link between these items of equipment. Home automation networks are built around an IEEE 1394 high speed serial bus to which this equipment subscribes. The audio and video stream data which has to be transmitted in real time is transferred in isochronous mode.
The international standard ISO/IEC 13818-1 relating to the encoding of MPEG 2 type audio and video data, with regard to the systems, describes a synchronization model for the entire chain, in other words for the encoding, transmission, decoding and display of the MPEG type pictures. The recovery of the system clock, on the decoder, is performed, for example, by locking, using a phase-locked loop, the local clock values on the reference clock values transported by the PCR of an incoming TS stream. The time of arrival of the PCR field must not cause any system clock drift as reproduced in the decoder, of more than 30 ppm, the precision imposed by the international standard ISO/IEC 13818-1.
An audiovisual layer has been defined to enable the receiver to offset the transmission time variations introduced by the 1394 bus. It is specified by the standard IEC 61883. A 12-byte header, in the case of the MPEG 2 data, containing a “time stamp”, is added to the data packets, the packets being made up of 188 bytes in the case of this MPEG 2 standard.
Before transmission over the bus, at the 1394 interface input, the packets are stamped, using the clock of the 1394 circuits, the precision of which, according to the standard, is 100 ppm. The audio-video packets are stored in the FIFO memory of the 1394 interface, and each packet receives a time sample, in fact a header, when it arrives in the memory. This memory acquires a certain number of packets during the 125 microsecond period, dependent on the input bit rate. When the 125 microsecond synchronization signal (“cycle start”) is triggered, these packets are transmitted over the 1394 bus, one after the other in burst mode.
After receipt of the packets from the bus, at the 1394 interface output, the stamp is read and compared with the content of a local counter to define the time at which the packet will be presented. This time sample is used to recreate the time distribution that applied at the FIFO input. The local counter is synchronized at each cycle start on the clock of the root node which generates the 125 microsecond reference period.
In the case of a direct link, in other words of a simple transfer via the 1394 bus, the difference between the time of stamping and the time of reading the tag is around a hundred microseconds. The writing, or more specifically, the tagging, of the data and the reading of this tag are performed on the basis of different local clocks which are, however, simultaneously synchronized every 125 microseconds on the master clock of the root node. Since writing and reading are virtually instantaneous, the effects due to the jitter or drift intrinsic to the synchronization mechanism of the IEEE 1394 bus and the precision of its clock system are not therefore translated into a drift in the time distribution of the packets at the output of the 1394 interface. Consequently, the 1394 bus does not alter the bit rate and this time-stamping according to the IEC 61883 standard solves the problem of loss of the time distribution of the MPEG 2 packets on transmission over the 1394 bus.
However, when a mass storage facility is associated with the audiovisual equipment, when the TS stream transmission chain is “cut”, typically because of the storage of the compressed data of this stream on a hard disk for subsequent reading, this specific problem of drift remains when the data passes over the 1394 bus.
The use of tagging in relation to the 1883 layer, for storage on the medium, does not solve the problem because of the precision of the 1394 synchronization clock, which is approximately 100 ppm. The time at which the data is stamped is different from the time at which the data is read from the hard disk. There is drift on the output bit rate of the 1394 interface because of the new time distribution of the packets associated with the change of clock frequency.
It can also be seen that the root node at the time of storage can be different from that at the time of reading. Consequently, at the time of tagging the clock can be synchronized on a master clock that is different from that used on reading the tag.
This drift on the bit rate and therefore on the times of arrival of the PCRs on which the local 27 MHz clock is synchronized, causes a frequency drift on that clock. Consequently, in the more or less long term, an underflow or overflow of the buffer of the MPEG decoder occurs, being reflected in a picture display fault on the receiver, typically a freezing of the picture at recurrent intervals.
Too great an offset of this synchronized clock can also impair the quality of the chrominance signals extracted from the subcarrier.
Modifying the precision of 100 ppm of a particular item of equipment would not solve the problem because any equipment can be declared the root node on writing and then on reading the data on the hard disk.
A known mode of operation, called “pull”, in which the data transfer rate from the hard disk to the decoder can be “controlled” by the decoder, typically according to the fill rate of the buffer of the decoder, can be used to avoid any underflow or overflow of this buffer. In this mode, the problems of clock precision are less crucial, since too great a drift of the decoder clock, caused by a drift in the bit rate, is corrected by regulation of the read mode stream bit rate, by the decoder, according to the fill rate of the buffer of the decoder. This mode of operation is not, however, possible in the case of TS stream storage which does not allow direct memory access (DMA) by the decoder. As for storage at the PES packet level, it does not allow this data to be transferred over the 1394 bus.
Thus, if the compressed data is not transmitted directly to a decoder but is stored on a storage medium, typically a hard disk, so that it can subsequently be read via a 1394 bus, problems of drift remain, causing a picture display fault at recurrent and more or less brief intervals.
The patent application filed in France on Jul. 17, 2000 and published under the number 2 811 846 solves this problem. The method of reading, from a storage medium, audio and video data encoded in packet form according to the MPEG standard, so that it can be transmitted to a decoder via a 1394 bus, which comprises a step for reading tags stored with the packets, these tags defining the times of arrival of the data packets to be stored, based on a tagging clock, and a step for comparing the tags with values counted on the basis of a transfer clock to define the times of transfer over the bus of the data read from the storage medium.
The operating frequencies of said tagging and transfer clocks must satisfy certain specifications, in particular with respect to the maximum difference between these frequencies or the drift if it is one and the same clock.
By time stamping the packets stored in the storage medium on the basis of a specific clock, the risks of underflow or overflow of the buffer of the decoder are minimized. There is then perfect compatibility for the storage and transfer of DV or MPEG type signals over a 1394 bus.
A particular problem occurs in the use of the trick modes described in the MPEG standard. The time-stamping of the packets and the creation of files containing the tags entail modifying the latter when using these trick modes. In practice, while this use does not pose problems locally, in other words when the decoder is the master, the same does not apply when operating a server, which, in normal mode, returns the data at the same rate as on storage. For example, when operating the fast forward mode, the server must increase the bit rate on transmission. Since it has the only file on disk containing the tags, one solution is to modify these tags stored in the files. The application makes this modification in real time. This solution is very bandwidth and central processing unit resource intensive. A modification of the tags not in real time, with rewriting of the modified tags on the medium, cannot be envisaged because it is too processing time intensive and does not allow for a response in virtually real time to the trick mode commands, which are by definition unpredictable.
Another solution is to have a large storage capacity locally, typically on the decoder, to perform simple trick mode functions, but this solution is video memory intensive.